The present disclosure relates to verification techniques, in general, and to improving coverage of a verification process in particular.
Computerized devices are an important part of modern life. They control almost every aspect of our life—from writing documents to controlling traffic lights. However, computerized devices are bug-prone, and thus require a verification phase in which the bugs should be discovered. The verification phase is considered one of the most difficult tasks in developing a computerized device. Many developers of computerized devices invest a significant portion, such as 70%, of the development cycle to discover erroneous behaviors of the computerized device, also referred to as a target device. The target device may comprise hardware, software, firmware, a combination thereof and the like.
The verification phase may be useful in finding bugs in both software and hardware (and combination thereof). Dynamic verification methods such as hardware simulation and software testing are the primary means of verifying the correctness of hardware and software. These methods are scalable and relatively easy to use. However, they have limited coverage and hence may miss critical corner bugs. This is especially true when the bugs are very rare. The common approach to maximizing coverage of simulation-based tools is to (manually) define a coverage model, which is a list of coverage goals which are then passed to simulation. A simulation process is complete when all coverage goals are reached. In the present disclosed subject matter, hardware simulation and software testing are both referred to as simulation. Simulation of hardware execution may be performed using a model of the hardware. Verification of software execution may be performed executing the software. In both cases, a stimulus may be utilized to force the System Under Test (SUT), be it software or hardware, to perform different functionalities. As only a portion of all possible stimuli are checked, determining a coverage measurement may be useful in understanding whether or not to continue performing verification. A stimulus may be input to the SUT from a user, an external component, an environment or the like. For example, a stimulus may be a scheduling decision on threads of the software, clock signal to the hardware or the like.